UNIVERSIDADE FEDERAL DE SANTA MARIA

CENTRO DE TECNOLOGIA

CURSO DE CIÊNCIA DA COMPUTAÇÃO

AUTOMAÇÃO DE INTERFACES GRÁFICAS

PARA MODELOS DE SIMULAÇÃO DE

CULTURAS AGRÍCOLAS COM BASE EM

LINGUAGEM DE PROGRAMAÇÃO VISUAL

TRABALHO DE GRADUAÇÃO

Romulo Pulcinelli Benedetti

Santa Maria, RS, Brasil

2016

AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA

MODELOS DE SIMULAÇÃO DE CULTURAS AGRÍCOLAS

COM BASE EM LINGUAGEM DE PROGRAMAÇÃO VISUAL

Romulo Pulcinelli Benedetti

Trabalho de Graduação apresentado ao Curso de Ciência da Computação da

Universidade Federal de Santa Maria (UFSM, RS), como requisito parcial para

a obtenção do grau de

Bacharel em Ciência da Computação

Orientadora: Profł. Drł. Andrea Schwertner Charão

Santa Maria, RS, Brasil

2016

Universidade Federal de Santa Maria

Centro de Tecnologia

Curso de Ciência da Computação

A Comissão Examinadora, abaixo assinada,

aprova o Trabalho de Graduação

AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA MODELOS DE

SIMULAÇÃO DE CULTURAS AGRÍCOLAS COM BASE EM

LINGUAGEM DE PROGRAMAÇÃO VISUAL

elaborado por

Romulo Pulcinelli Benedetti

como requisito parcial para obtenção do grau de

Bacharel em Ciência da Computação

COMISSÃO EXAMINADORA:

Andrea Schwertner Charão, Drł.

(Presidente/Orientadora)

Nereu Augusto Streck, Prof. Dr. (UFSM)

João Vicente Ferreira Lima, Prof. Dr. (UFSM)

Santa Maria, 06 de Julho de 2016.

RESUMO

Trabalho de Graduação

Curso de Ciência da Computação

Universidade Federal de Santa Maria

AUTOMAÇÃO DE INTERFACES GRÁFICAS PARA MODELOS DE SIMULAÇÃO

DE CULTURAS AGRÍCOLAS COM BASE EM LINGUAGEM DE PROGRAMAÇÃO

VISUAL

AUTOR: ROMULO PULCINELLI BENEDETTI

ORIENTADORA: ANDREA SCHWERTNER CHARÃO

Local da Defesa e Data: Santa Maria, 06 de Julho de 2016.

A automação de tarefas é uma forma bastante eﬁciente pela qual podemos reduzir custos

e aumentar a produtividade e qualidade da atividade humana. A computação por si é uma

ferramenta para atingir a automação de tarefas, com vários exemplos de softwares focados em

automatizar tarefas especíﬁcas sob comando do usuário, sendo a automatização destes softwares

um campo a parte. Observamos a aproximação destes softwares a abordagens mais naturais ao

raciocínio humano, por meio de interfaces gráﬁcas e contextualização dos elementos com base

no mundo real, tornando estes softwares menos distantes do paradigma de interação do humano

com a realidade. Desta forma este trabalho objetiva abordar a utilização de tecnologias voltadas

a programação visual, em especial a biblioteca para criação de linguagens visuais, Blockly, para

melhorar a abordagem de automação de tarefas, com foco em softwares gráﬁcos de modelagem

matemática agrícola, assim inserindo a atividade de automatizar estes softwares gráﬁcos, dentro

do mesmo domínio de abstração que as atividades destes softwares ocorrem.

Palavras-chave: Automação de Software. Linguagens de Programação Visual. Modelos de

Simulação de Culturas Agrícolas. Automação de Interfaces Gráﬁcas. Blockly.

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1 Objetivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.1 Objetivo Geral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.2 Objetivos Especíﬁcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Justiﬁcativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 REVISÃO DE LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Automação e suas abordagens dentro da computação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Programação visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Modelos matemáticos de simulação de culturas agrícolas. . . . . . . . . . . . . . . . . . . . . . . . . 11

3 DESENVOLVIMENTO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Concepção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Elaboração dos casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Analise dos casos de uso em outras ferramentas de automação . . . . . . . . . . . . . . . . . . . . . 20

3.1.3 Coleta dos requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Entradas e saídas do software a ser autoamatizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Modelagem do software Automatizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Desenvolvimento do software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Interação entre automatizador e software a ser automatizado . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2 Construção de automatizações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.3 Codiﬁcação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.4 Blockly em uma aplicação Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.5 Interação e pesquisa por regiões na tela do sistema operacional . . . . . . . . . . . . . . . . . . . . 29

3.3.6 modelagem das funcionalidades no softwares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Validando solução com os casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.1 Simanihot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1 INTRODUÇÃO

No desenvolvimento de software, áreas de conhecimento como engenharia de software

e qualidade de software investigam processos e normas, com o objetivo de reduzir a quantia

de recursos necessários e garantir a qualidade de software produzido. Um dos produtos destas

áreas, envolvendo automação, foi o campo de conhecimento de testes de software.

Sendo que o software pode realizar diversas tarefas, e estas podem assumir diversos

estados, qualquer abordagem de teste de software, numa situação ideal deveria avaliar todas

estas tarefas e seus estados para fornecer as melhores informações possíveis sobre a qualidade

do software, o que facilmente pode se tornar uma tarefa repetitiva e de longa duração e na

maioria dos casos nem sempre é possível, segundo (MYERS; SANDLER; BADGETT, 2011,

pag. 10).

Embora nem sempre seja possível testar todos os estados possíveis, é possível realizar

os testes em uma faixa conhecida e ﬁnita de estados. Nestes casos, usar ferramentas como

frameworks voltados a automatização destes testes agiliza a tarefa de repetir os testes, como na

abordagem de testes de regressão onde todos os testes devem ser executados novamente a cada

ciclo de desenvolvimento.

Estas ferramentas oferecem também uma série de vantagens tais como precisão ao re-

duzir a necessidade da atenção humana durante o andamento da tarefa, acelerando atividades e

melhorando o aproveitamento do tempo de trabalho humano.

Alguns destes frameworks, embora voltados a realização de testes, poderiam ser usa-

dos para automatizar programas gráﬁcos. Um exemplo disso é o Robot Framework (ROBOT

FRAMEWORK, 2015). Entretanto, são ferramentas que, apesar de cobrirem de forma bastante

detalhada a automação de testes, não são as mais adequadas à modelagem da automatização

de softwares gráﬁcos, dependem de um domínio de assuntos de diversos campos da área de

Ciências da computação e em muitos casos, domínio da especiﬁcação e arquitetura do software

a ser automatizado ou ainda alterações a nível de codiﬁcação no programa a ser automatizado.

Já outros casos particulares de automatização focada em tarefas de TI são os próprios

terminais ou ainda utilitários como shell, make e aﬁns. Tratam-se de ferramentas e linguagens

voltadas para automatização do desenvolvimento e de tarefas administrativas, também inade-

quadas à automatização de programas gráﬁcos, seja por serem bastante limitadas a um mundo

formalmente textual, pela complexidade de sua sintaxe ou ainda pela abstração focada em ta-

refas comuns apenas para proﬁssionais de TI e para software que oferece interface com estes

utilitários.

Existem também ferramentas destinadas à automação de software gráﬁco, como a lin-

guagem script de automatização Autoit (AUTOIT, 2015). Ainda assim, é uma ferramenta que

exige o domínio de um nível de abstração elevado, perceptivelmente diferente da abstração em

que a atividade se dá, em um ambiente gráﬁco, focado em facilidades visuais de interação.

A automatização de tarefas pode ser aproximada do usuário por meio de abordagens

mais visuais e sintaxe mais contextualizada à modelagem de tarefas genéricas em interfaces

gráﬁcas, com o uso de linguagem visual para descrição das automações, onde um exemplo

de ferramenta para construção de linguagens visuais é a biblioteca Blockly (BLOCKLYRE-

SOURCE, 2015) usada neste projeto.

Um tipo de software que se beneﬁciaria da automatização de tarefas é o de simulação de

culturas agrícolas. Os modelos de simulação vem sendo reﬁnados para prever o comportamento

(por exemplo, taxa de crescimento) de diferentes cultivares sob determinadas condições do am-

biente (por exemplo, volume de chuvas). Alguns exemplos de modelos em uso hoje em dia são

SoySim (SOYSIM, 2015) (soja), Simanihot (SIMANIHOT, 2015) (mandioca) e DSSAT (De-

cision Support System for Agrotechnology Transfer) (DECISION SUPPORT SYSTEM FOR

AGROTECHNOLOGY TRANSFER , DSSAT) (diversos cultivares). Embora estejam se tor-

nando signiﬁcativamente mais fáceis de interagir por via gráﬁca, dependendo das atividades

realizadas e da forma como o modelo as realiza, trabalhar com estes programas pode se tornar

uma atividade manual repetitiva e demorada. Tarefas como simulações em climas futuros é um

dos exemplos mais notórios desta situação.

A automatização destes modelos via uma abordagem mais visual permitiria a obtenção

das vantagens aqui discutidas, sem deslocar o utilizador de sua área de domínio, a interface

gráﬁca.

1.1 Objetivos

1.1.1 Objetivo Geral

O principal objetivo deste trabalho é tornar possível a automação de tarefas em inter-

faces gráﬁcas por meio da simpliﬁcação de uma abordagem visual com base na biblioteca de

programação visual Blockly (BLOCKLYRESOURCE, 2015), dentro do contexto de modelos

de simulação de culturas agrícolas.

1.1.2 Objetivos Especíﬁcos

• Fornecer uma solução menos formal e textual, mais visual e contextualizada, de automa-

tização;

• Automatizar tarefas computacionais em interfaces gráﬁcas no campo de modelagem ma-

temática agrícola;

• Auxiliar o campo de pesquisa e trabalho com modelos matemáticos de culturas agrícolas;

1.2 Justiﬁcativa

A automação de tarefas é hoje em dia um processo fundamental para a obtenção de re-

sultados ágeis e de qualidade, tanto na produção de um produto ou no fornecimento de serviços,

assim como na execução de tarefas pessoais. Representa também redução de custos, o que abre

novas possibilidades permitindo trabalhos mais complexos e maiores chances de sucesso. En-

tretanto, ferramentas de automação na computação têm exigido um domínio de abordagens de

abstração que, em geral, vão além da abstração com a qual, usuários ﬁnais de outras áreas estão

acostumados. Uma abstração mais próxima ao nível em que estas tarefas ocorrem tornaria a

automação um processo mais intuitivo.

Uma destas áreas de conhecimento é a Fitotecnia, mais especiﬁcamente, estudos do de-

senvolvimento da fenologia e produtividade de culturas que hoje utilizam modelos de simulação

de culturas agrícolas. Essa área evoluiu para programas com interfaces gráﬁcas, objetivando al-

cançarem e beneﬁciarem mais pessoas, leigas em computação porém ﬂuentes na área de conhe-

cimento da ferramenta. Em alguns casos, as tarefas realizadas com estes simuladores envolvem

interações repetitivas para obter uma grande faixa de amostragem de resultados, tarefas estas

que se beneﬁciariam da automatização e estariam igualmente acessíveis ao domínio de seus

usuários, caso esta automatização pudesse ser realizada dentro deste domínio de entendimento,

um ambiente e uma metodologia visual.

2 REVISÃO DE LITERATURA

Na sequência serão apresentados conceitos relativos aos conteúdos abordados nesse tra-

balho, descrevendo a automação, sua utilização dentro computação na área de TI e os resultados

até então obtidos na automatização de tarefas mais genéricas, assim como linguagens de pro-

gramação visual e o Blockly, ferramenta com a qual este aspecto será tratado.

2.1 Automação e suas abordagens dentro da computação

A automação é a execução de tarefas por meio de máquinas e computadores, antes exe-

cutáveis apenas por humanos (PARASURAMAN; SHERIDAN; WICKENS, 2000). Segundo

NOF (NOF, 2009, pág. 124), a automação teve um impacto signiﬁcativo na economia e de-

senvolvimento tecnológico da sociedade. É um elemento-chave para o alcance de produtos e

serviços de alta qualidade e baixo custo. Uma das áreas impactadas pela automação foi a preci-

são em um ciclo autoalimentado, onde a automação melhora a precisão e por sua vez a precisão

melhora a automação (DONMEZ; SOONS, 2008).

A automação da informação por meio de computadores, segundo NOF (NOF, 2009, pág.

3) é um processo dos dias atuais, onde temos vendas automatizadas de passagens, conexões de

chamadas em nossos telefones, realizadas de forma automática, dentre outras mudanças advin-

das da automatização. Temos também a produção e manufatura por intermédio da robótica. No

ﬁnal das contas, o impacto da informática promoveu não só uma intensa automatização pas-

siva, mas também, segundo VENKATRAMAN(VENKATRAMAN, 1994), tem criado e man-

tido ﬂexíveis redes de negócios, inclusive transformando a forma como realizamos negócios e

atividades.

Dentro da área de computação, observamos a automação agilizar e reﬁnar tarefas como

testes, desenvolvimento e manutenção de projetos, devido ao reconhecimento de que o desen-

volvimento de software muitas vezes consiste na criação sistemática de componentes que devem

aderir a um conjunto bem especíﬁco de restrições (BARRY; KEMERER; SLAUGHTER, 2007).

Segundo BARRY; KEMERER; SLAUGHTER(BARRY; KEMERER; SLAUGHTER,

2007), a automação do processo de desenvolvimento tem o potencial de reduzir o erro humano

em código que deve se adequar a sintaxe e restrições precisas, podendo inclusive produzir soft-

ware de melhor qualidade que o produzido manualmente, considerando que o talento em desen-

volvimento de software é escasso, representando também uma redução de custo. Também reduz

a necessidade de interação humana com tarefas secundárias ou de pouco interesse, contribuindo

para redução da complexidade da tarefa.

Dentre tarefas comuns na área de TI, temos a automatização de tarefas administrativas

via linguagens e ferramentas tais como um shell e linguagem script especíﬁca, ou ainda ferra-

mentas de automatização focadas em tarefas de desenvolvimento, como make, ferramenta de

automação de builds, ou como Robot Framework, ferramenta voltada à automação de testes

(UNIX SHELL, 2015; GNU MAKE, 2015; ROBOT FRAMEWORK, 2015).

Considerando que TI não é a única área onde tarefas repetitivas, bem deﬁnidas e res-

tritas ocorrem, o interesse em automatizar estas tarefas resultou em software tal como o Au-

toIt(AUTOIT, 2015), para plataforma Windows, um programa que permite automatizar progra-

mas com interface por meio da descrição da automatização em uma linguagem script, podendo

gerar executáveis independentes que rodam em computadores que não tenham o AutoIt insta-

lado. Essa ferramenta tem à disposição uma grande diversidade de bibliotecas com funções

prontas, tendo inclusive uma IDE voltada para sua linguagem de automação. Outro exemplo

é o Automator, que permite automatizar tarefas repetitivas em plataformas Macintosh, permi-

tindo construir workﬂows por meio de unidades modulares chamadas ações; apesar de conter

diversas ações pre estabelecidas, é possível inserir novas ações por meio de linguagens como

AppleScript e Objective-C (AUTOMATOR, 2015).

Existem outras ferramentas que se propõem a solucionar estes problemas de automati-

zação em interfaces gráﬁcas, com características diversas, algumas delas proprietárias, outras

com uma linguagem mais visual e informal que linguagens script e código tradicional, tais

como o UiPath, Sekulix e o TestComplete (UIPATH, 2015; TESTCOMPLETE, 2015; SIKULI,

2015), ferramentas que abordam a automação de uma forma mais abstrata, porém com uma

ﬂexibilidade lógica limitada por esta abstração.

2.2 Programação visual

Segundo SHU(SHU, 1988), programação visual é “o uso de representações gráﬁcas sig-

niﬁcativas no processo de programação” realizada em uma linguagem que SHU deﬁne como

“uma linguagem que utiliza alguma representação visual para completar o que outrora deve-

ria ser escrito em uma linguagem uni-dimensional tradicional”. Esta deﬁnição hoje tem se

mostrado um tanto ampla e tem apresentado diversas contextualizações como podemos ver em

(KOEGEL; HEINES, 1993), que apresenta programação visual no contexto de autoria multimí-

dia.

No contexto do presente projeto, programação visual representa a programação de tare-

fas de automatização de programas com interface gráﬁca, com base em elementos visuais por

meio do Blockly (BLOCKLYRESOURCE, 2015). Esta é uma biblioteca de código aberto des-

tinada à criação de editores para programação visual, totalmente baseada em tecnologias web e

portável. Trata-se de uma ferramenta que executa do lado do cliente, funcionando na maioria

dos navegadores web e em dispositivos móveis ( BLOCKLYRESOURCE, 2015).

Blockly pode ser integrado a qualquer aplicação que ofereça um componente web e é ca-

paz de oferecer teste de unidade, possibilidade de tradução, tratamento de eventos e construção

de blocos customizáveis, permitindo inclusive mutabilidade. O processo de criação dos blocos

consiste em deﬁnir seu formato, campos e pontos de conexão e se necessário, modiﬁcadores,

o que pode ser realizado com o uso do Block Factory ou ainda da API JSON. Em seguida é

criado o gerador de código para que o novo bloco possa ser exportado para alguma linguagem

de programação.

Um exemplo tipico de deﬁnição de um bloco:

1 Blockly.Blocks[’text_length’] = {

2 init: function() {

3 this.setColour(160);

4 this.appendValueInput(’VALUE’)

5 .setCheck(’String’)

6 .appendField(’length of’);

7 this.setOutput(true, ’Number’);

8 this.setTooltip(’Returns number of

9 letters in the provided text.’);

10 this.setHelpUrl(’http: / / www.w3schools.com/

11 jsref/jsref_length_string.asp’);

12 }

13 };

Embora Blockly não seja escalável para grandes programas, pode ainda ser usado como

um editor de linguagens visuais para áreas especíﬁcas, apresentando elementos comuns a lin-

guagens de programação tais como funções, variáveis, arrays, checagem básica de tipos e aﬁns.

Por ser uma ferramenta para criação de editores de linguagens visual, impossibilita que o usuá-

rio cometa erros de sintaxe ao fazer programas via Blockly.

A ﬂexibilidade da ferramenta pode ser observada na utilização para criação de jogos,

aplicativos móveis para Android, programação web ou ainda como recurso educacional (BLOC-

KLYGAMES, 2015; APPINVENTOR, 2015; MARRON; WEISS; WIENER, 2012; SILVEIRA Jú-

NIOR et al., 2015).

2.3 Modelos matemáticos de simulação de culturas agrícolas

Neste projeto serão usados modelos matemáticos que simulam diversos processos eco-

ﬁsiológicos de culturas Agrícolas. Em geral, estes modelos trabalham dentro de um ciclo diá-

rios, em função de variáveis meteorológicas que englobam temperatura, umidade do ar, radiação

solar, precipitação, nível de CO2 atmosférico, dentre outros, com base na localização geográ-

ﬁca a ser simulada. Alguns modelos também utilizam condições do solo, que podem envolver

balanço hídrico e nível de nutrientes disponíveis e, por ﬁm, o tipo de cultivar sendo simulada, no

caso como variáveis que descrevem como ocorre seu desenvolvimento (STRECK et al., 2015).

Os modelos que serão usados para estudo de caso em conjunto com a ferramenta desenvolvida

no projeto são o Simanihot, SoySim e DSSAT.

O Simanihot é um modelo matemático dinâmico baseado em processos (process-based

model). Foi projetado para trabalhar em ciclos diários e simula diversos processos eco-ﬁsiológicos

da cultura da mandioca. O modelo foi desenvolvido pelo grupo Agrometeorológico da Univer-

sidade Federal de Santa Maria e é destinado a simular o crescimento, desenvolvimento e produ-

tividade da cultura em questão no estado do Rio Grande do Sul, Brasil. O modelo utiliza como

dados de entrada, as datas de plantio e de colheita, dados meteorológicos e balanço hídrico do

solo, sendo um programa disponibilizado de forma gratuita (SIMANIHOT, 2015).

Outro modelo usado neste projeto, o SoySim, simula o desenvolvimento da cultura de

soja e foi desenvolvido pela Universidade de Nebraska-Lincoln. Este modelo simula o po-

tencial de rendimento, assim como as necessidades de irrigação, sem limitação pela irrigação

e assumindo suplemento ideal de nutrientes e sem perdas de rendimento por inﬂuências do

ecossistema, tais como granizo, ou de outros meios, tais como envenenamento por nitritos ou

nitratos. O ciclo de simulação deste modelo também é diário (SOYSIM, 2015).

Já o DSSAT é um programa que engloba diversos modelos de simulação de culturas

agrícolas, num total de 42 culturas. Oferece suporte ao manejamento de solo, clima e culturas

assim como dados experimentais, por via também de utilitários e outros programas. Os modelos

disponíveis simulam o crescimento, desenvolvimento e potencial como uma função de condi-

ções agrometeorológicas, tendo sido usado tanto no reﬁno de manejo, em fazendas ou para

análise de impacto climático sobre as culturas suportadas (DECISION SUPPORT SYSTEM

FOR AGROTECHNOLOGY TRANSFER , DSSAT).

3 DESENVOLVIMENTO

Na sequência, serão descritas as tarefas desenvolvidas para se chegar no objetivo pro-

posto por este trabalho. Na primeira etapa será realizada a concepção do software automati-

zador, onde serão analisados problemas de automação em softwares de simulação de culturas

agrícolas e soluções existentes para automatização de interfaces gráﬁcas, levantando os requisi-

tos necessários para a solução dos problemas de automação destes softwares, dentro do objetivo

proposto. Após a concepção Será modelada uma solução, procurando compreender que compo-

nentes são necessários e por qual motivo eles necessitam ser criados. Finalmente será realizado

o desenvolvimento do software, veriﬁcando as diversas abordagens para criação dos componen-

tes, discutindo as escolhas realizadas apos veriﬁcação das abordagens possíveis.

3.1 Concepção

Nesta etapa serão apresentados casos de uso obtidos com três atores, e posteriormente,

uma análise com três ferramentas já existentes para automação de tarefas em programas com

interface gráﬁca, o UiPath, o Sikuli e o Autoit, procurando embasar o objetivo deste projeto,

os requisitos da solução e as decisões tomadas durante a modelagem e desenvolvimento do

software.

3.1.1 Elaboração dos casos de uso

Com as reuniões realizadas semanalmente no primeiro mês, foram discutidos e coletados

três casos de uso com estudantes da área de agrometeorologia no Departamento de Fitotecnia

da UFSM, procurando entender as necessidades de automatização dos estudantes em cada um

dos modelos com o qual trabalham.

O primeiro caso de uso é referente as necessidades da Engenheira Agrônoma Amanda

thirza Lima, mestranda no programa de Pós-Graduação em Agronomia da UFSM, nas ativida-

des de seu projeto de dissertação para indicar um novo zoneamento agroclimático para a cultura

de mandioca no estado do Rio Grande do Sul utilizando o programa Simanihot, modelo de

simulação da cultura da mandioca.

No segundo caso de uso foi tratado o objetivo da Jossana Ceolin Cera, Meteorologista

e Doutora em Engenharia Agrícola pela Universidade Federal de Santa Maria, com objetivo

já realizado durante seu doutorado de forma completamente manual, onde foi usado o modelo

SoySim para simular o crescimento, desenvolvimento e produtividade de Soja para o estado do

Rio Grande do sul.

O último caso de uso foi referente a tese de Cesar Augusto Fensterseifer, graduado em

Engenharia Ambiental, Mestre em engenharia civil e ambiental e atualmente aluno de doutorado

do programa de pós-graduação em engenharia agrícola da UFSM, que deseja gerar previsões de

safra de soja para auxiliar no planejamento agrícola do Estado do Rio grande do Sul.

Em todos os casos de uso as pré e pós condições são as mesmas, no caso, a ferramenta

deve iniciar em condição de realizar uma automatização e ﬁnalizar em um estado capaz de

iniciar novamente a mesma automatização. Os três casos de uso são descritos em ordem:

Caso de Uso 1: Automatização de simulações no modelo Simanihot para novo zonea-

mento agroclimático para a cultura de mandioca

breve descrição: Para o desenvolvimento da tarefa é preciso fazer muitas simulações

para que se possa indicar os melhores dias de plantio em uma série histórica de anos agrícolas.

Para que sejam realizadas essas indicações é necessário que sejam realizadas simulações diárias

da data de plantio de primeiro de julho a 31 de dezembro para todos os anos desde 1960 a 2015,

para 18 locais utilizando 4 cultivares; é necessário também fazer uma simulação para uma

cultivar, em uma única data de plantio, local e ano especiﬁco.

Fluxo Principal:

1. Os seguintes campos são preenchidos, mas não variam: concentração de dióxido de car-

bono (CO2) 400 ppm, densidade de plantio 15625 plantas por hectare, simulação a partir

do plantio, data de colheita (15/06), modelo de balanço hídrico de Thornthwaite e Mather

e respectivamente neste modelo de balanço hídrico, a profundidade de maniva 8 cm e

profundidade máxima de raiz 30cm.

2. Será inserido um arquivo de entrada para cada local (Bagé, Bento Gonçalves, Bom Je-

sus, Caxias do Sul, Cruz Alta, Encruzilhado do Sul, Irai, Lagoa Vermelha, Passo Fundo,

Pelotas, Porto Alegre, Rio Grande, Santa Maria, Santa Vitória do Palmar, Santana do Li-

vramento, São Luiz Gonzaga, Torres, Uruguaiana). Para cada arquivo será utilizado um

tipo especíﬁco de solo e será selecionado o local especíﬁco.

3. As simulações serão realizadas para 3 cultivares, sendo elas FEPAGRO RS13, Estran-

geira e São José.

4. Para cada arquivo de entrada, serão realizadas simulações que variam de n = 1

r de agosto

até 31 de dezembro, com variando de um em um dia.

5. A data de colheita não variará com as simulações, será sempre dia 15 de junho.

6. Depois de completar todos esses passo, ﬁnalmente clicará no botão SIMULAR.

Fluxo Secundário:

1. Nenhum

Fluxo de exceção:

1. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-

lação e esperar que o usuário recomece a automação ou cancele.

2. No caso de encontrar algum alerta de campo preenchido incorretamente, encerrar a auto-

mação e envia o usuário para a pós condição.

Caso de Uso 2: Automação de simulações no modelo SoySim para simular o cresci-

mento, desenvolvimento e produtividade de Soja para o estado do Rio Grande do sul

breve descrição: Fazer simulações para 37 pontos espalhados no Rio Grande do Sul (37

arquivos de dados meteorológicos), com 120 anos de dados em cada arquivo, de 1980 a 2099,

utilizando 7 datas de semeadura (01/08, 01/09, 01/10, 01/11, 01/12, 01/01 e 01/02) e 3 grupos

de maturação (4.8, 5.5 e 6.0), em 2 cenários climáticos futuros. Dois conjuntos de dados com

37 arquivos de dados meteorológicos cada um. Dividindo cada um desses 37 arquivos em 3

arquivos com 45 anos de dados, pois o modelo SoySim não suporta fazer a simulação com um

arquivo de dados tão extenso.

Fluxo Principal:

1. Inserir um arquivo de entrada para cada ponto (2751 19602007, 2751 20062053, 2751

20522099, 2752 19602007, 2752 20062053, 2752 20522099 e assim por diante).

Figura 3.1: Fluxograma do caso de uso 1.

2. Realizar as simulações para os grupos de maturação (4.8, 5.5 e 6.0).

3. Para cada arquivo de entrada realizar simulações que variam de 01 de agosto até 01 de

fevereiro, iniciando na semeadura, de um em um mês

4. Modiﬁcar a densidade de população de plantas para 315.

5. Depois de preencher estes campos, clicar no botão run.

6. Copiar os dados a partir da linha 14 a 59 do arquivo de resultado TmpOut.txt e armazenar

todos em um só resultado ﬁltrando itens especíﬁcos e gerar um arquivo de resultado com

o mesmo.

Fluxo Secundário:

1. Reiniciar a automação alterando a automação para que a mesma não seja rodada na função

de multiple years mas sim seja rodada na função de single years, onde cada ano precisa

ser deﬁnido na interface.

2. Copiar a linha 35 do arquivo resultante TmpOut.txt e adicioná-la ao ﬁnal de um arquivo

de resultado único.

Fluxo de exceção:

1. No caso de encontrar algum alerta de campo preenchido incorretamente, encerrar a auto-

mação e envia o usuário para a pós condição.

2. Caso o modelo apresente um alerta rodando no ﬂuxo principal o programa deve passar

para o ﬂuxo secundário

3. Caso o alerta seja recebido enquanto o modelo já está no ﬂuxo secundário, passar para o

ano seguinte da lista de anos da automação.

4. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-

lação e esperar que o usuário recomece a automação ou cancele.

Figura 3.2: Fluxograma do caso de uso 2.

Caso de Uso 3: Automação de simulações no modelo DSSAT para gerar previsões de

safra de soja para auxiliar no planejamento agrícola do Estado do Rio grande do Sul

breve descrição: O RS é um dos Estados brasileiros que mais sente os efeitos dos

fenômenos El Nino e La Nina, e atualmente é o terceiro maior responsável pela produção de

soja do País. É necessário gerar previsões de safra de soja para auxiliar no planejamento agrícola

do Estado do Rio grande do Sul (RS). gerando várias simulações no modelo para diversas datas

de semeadura.

Fluxo Principal:

1. Abrir o DSSAT, esperar carregar e clicar em Crop Management Data. A partir dessa ação,

o programa XBuild inicializará, e o usuário deve então clicar em New (para começar a

criar um experimento).

2. Criar um nome inexistente para o experimento. Institute Code (SM para UFSM), Site

Code (RS se for dentro do RS), Year (2013), Experiment Number (99 datas de semeadura),

por exemplo. Lembrando que o usuário é livre para escolher a forma de preencher as

lacunas dessa etapa do experimento, de uma forma que o torne auto-explicativo. No

campo Crop (selecione Soybean). As demais lacunas podem ser preenchidas com -99.

3. Nessa etapa o usuário clica em Environment e depois em Fields. Aqui basicamente deve

ser informado qual a série meteorológica o experimento vai utilizar, se existe algum tipo

de drenagem e as características do solo daquela região. Ao rodar o modelo para ou-

tro local, o usuário deve adicionar mais um level e repetir o preenchimento com a série

meteorológica e as características do segundo local, e assim sucessivamente.

4. O usuário clica em Management e seleciona Cultivars, a tela sera redirecionada para

uma seção onde deve ser selecionada a cultivar ou as cultivares que serão utilizadas nas

rodadas do modelo. Lembrando que essas já devem estar devidamente calibradas pois

caso contrário, o nome da cultivar não aparecera na lista de seleção.

5. Inserção da data ou datas de semeadura, data de emergência, o método utilizado, a forma

de distribuição das sementes, a densidade de sementes na semeadura, a densidade de

plantas na emergência, o espaçamento entre linhas adotado, a direção das linhas em rela-

ção ao Norte e a profundidade de semeadura utilizada para um ou vários experimentos.

Lembrando que se o experimento possui alguma característica diferente, esse deve ser

inserido como um Novo Level.

6. Determinar a data que o modelo vai começar a simulação do balanço hídrico ou de nutri-

entes no solo. É aconselhado começar o balanço hídrico no solo entre 20 e 30 dias antes

da data de semeadura, buscando uma simulação mais precisa das condições do solo na

hora da semeadura.

7. Selecionar os balanços que gostaria que o modelo realizasse em cada experimento. Aqui

pode ser ativado ou não o balanço hídrico, de nitrogênio entre outras. Esses detalhes

podem aumentar o desempenho das simulações.

8. Decidir os métodos que serão utilizados nos balanços que foram selecionados no passo

anterior. Se o balanço hídrico foi selecionado, aqui o usuário deve selecionar o método

que o modelo deve utilizar para as rodadas em cada experimento. Essa regra também vale

para os outros balanços que o usuário deseja que o modelo realize.

9. Caso o usuário tenha dados mais especíﬁcos ou tenha utilizado irrigação em algum dos

experimentos que deseja simular, essa é a etapa em que vai inserir as características do

manejo utilizado.

10. Seleciona as informações que serão exibidas no ﬁnal das rodadas como: Crescimento de

massa seca diária, balanço hídrico....entre outros.

11. Caracterizar cada experimento, identiﬁcando cada experimento que vai utilizar a primeira

estação meteorológica por exemplo, ou o solo número 1 entre outras informações.

12. Após realizar essas etapas o usuário deve clicar no botão Refresh, que irá atualizar as

novas informações e posteriormente pode abrir o programa DSSAT e começar a rodar os

experimentos cadastrados.

Fluxo Secundário:

1. Nenhum

Fluxo de exceção:

1. No caso de encontrar algum alerta conhecido do modelo tais como alerta de temperatura

máxima menor que a mínima, encerrar a automação e envia o usuário para a pós condição.

2. Em caso de qualquer interação do usuário durante a tarefa de automação, pausar a simu-

lação e esperar que o usuário recomece a automação ou cancele.

3.1.2 Analise dos casos de uso em outras ferramentas de automação

Após a coleta dos casos de uso, foi analisado como outras ferramentas existentes atual-

mente, modelam os problemas observados nos casos de uso coletados, objetivando compreender

como e sob quais condições, estas ferramentas conseguem solucionar os casos de uso.

Dentre as ferramentas escolhidas, foram selecionados três programas de automação de

interfaces gráﬁcas capazes de solucionar os casos de uso. Os três programas escolhidos foram

descritos na revisão bibliográﬁca deste projeto, sendo estes, UiPath, Sikuli e Autoit.

Como forma de avaliação adicional do quanto estas ferramentas se mostram acessíveis

aos domínios de conhecimento do usuário, foi proposto a um dos atores dos casos de uso, que

este tentasse utilizar as mesmas ferramentas de automação descritas na revisão literária, para

resolver seu caso de uso. Descrevendo a experiência de forma objetiva, em prós e contras,

analisando se foi obtido sucesso ou não e onde os problemas responsáveis pelas falhas se origi-

naram, caso encontrado algum.

UiPath:

Prós: O programa permite virtualmente a realização de qualquer tarefa por meio da cons-

trução de um ﬂuxograma, com diversos elementos, vários deles autoexplicativos, tais como

as regras de interação de clique e digitação na interface dos modelos matemáticos. Fornece

lógica suﬁciente para as repetições e iterações necessárias nos casos de uso, também permite

mover ou renomear arquivos para que as rodadas não se sobrescrevam no caso 2.

Contras: O programa é muito complexo, fator especialmente observado ao tentar modelar

regras para o tratamento de erros no caso 1 e 2, contem muitas opções, elementos carregados

e complexos e poucas funções realmente genéricas. Em outro exemplo de complexidade, al-

guns elementos envolvem expressões VisualBasic. Depende da chamada de métodos externos

ao programa para tarefas não contempladas pelos elementos de ﬂuxograma, fator necessário

no parsing de valores em arquivos necessários para o caso 2, o que envolve métodos tra-

dicionais de automação, com linguagens de programação convencionais, podendo recorrer

inclusive ao powershell.

Sikuli:

Prós: O programa é fácil de entender com elementos autoexplicativos e não muito comple-

xos, é capaz de realizar as tarefas básicas tais como interagir com a interface do modelo e

esperar por eventos.

Contras: Para os casos de uso, os elementos visuais presentes não são suﬁcientes e não con-

templam repetições, trabalhar com arquivos, tratar erros, dentre outros, tornando necessário

que o usuários recorra a linguagem Python para realizar a automação.

AutoIt

Prós: Novamente um programa capaz de realizar virtualmente qualquer tarefa. Apesar de sua

abordagem bastante tradicional de programação em texto, possui uma biblioteca bem ampla

de funcionalidades.

Contras: O programa é totalmente dependente de linguagem script tipo BASIC própria, sem

nenhum elemento visual ou autoexplicativo. A automação se torna um desaﬁo possivelmente

tão grande quanto o problema original, já que o usuário precisa conhecer com certa profun-

didade a linguagem, o programa e as bibliotecas do AutoIt.

Analise do caso de uso 2 realizada pelo autor de forma direta nos 3 programas de auto-

mação sugeridos sem intervenção de terceiros ou qualquer pessoa do domínio da área:

Caso de uso 2 Analisado pelo ator

Automação de simulações no modelo SoySim para simular o crescimento, desenvolvimento

e produtividade de Soja para o estado do Rio Grande do sul.

UiPath:

Prós: Conseguiu fazer com que o software rodasse o SoySim para SingleYear e LongTerm-

Run. Uma rodada sozinha.

Contras: Não conseguiu inserir um loop para que múltiplas rodadas fossem feitas, também

não conseguiu fazer com que o programa mudasse os arquivos de entrada automaticamente.

Além disso, não conseguiu fazer com que o programa entendesse a janela de erro do SoySim.

Sikuli:

Prós: consegui montar o scrit que é no mesmo formato do UiPath (visual).

Contras: Na hora de rodar, o programa apresentou um erro que o ator não consegue inter-

pretar, erro apresentado na ﬁgura 3.3. Desistiu da ferramenta devido ao erro.

AutoIt

O ator não conseguiu compreender minimamente como a ferramenta funciona, foi capaz

de perceber que o programa usa código textual para automatizar as tarefas mas por não ter

profundo contato com linguagens de programação ou BASIC, não foi capaz de encontrar uma

solução intuitivamente ou em tempo hábil no manual do programa. Desistiu da ferramenta

devido à diﬁculdade.

Figura 3.3: Erro obtido pelo autor no programa Sikuli.

Observando as informações obtidas ao analisar os casos de uso com outras ferramentas

de automação, foram encontrados alguns pontos relevantes para a Proposta do projeto.

1. Linguagens de programação tradicional não contribuem para os atores solucionarem seus

problemas e inclusive diﬁcultam a obtenção de uma solução em alguns casos.

2. Apesar de possibilitar a solução, teoricamente, de qualquer problema inclusive fora da

automação de interfaces gráﬁcas, linguagens de programação tradicional são desnecessa-

riamente complexas para os atores e inclusive, para o problema deste projeto, aumentaram

as duvidas dos atores e problemas que eles precisavam considerar durante a obtenção de

uma solução, tal como a validade sintática de suas soluções assim como coleta de infor-

mações em outras fontes com relação a vocábulos e semântica da linguagem.

3. Os momentos em que os atores mais se beneﬁciaram das ferramentas analisadas foi

quando as mesmas ofereceram, componentes sucintos e autoexplicativos, ou seja, que

descreviam o que fazem, como usá-los e como não usá-los.

4. O segundo momento em que os atores mais se beneﬁciaram das ferramentas analisadas

foi quando os componentes oferecidos interagiam com os atores, impedindo maneiras

incorretas de seu uso ou explicitando o uso correto por meio de diversas simbologias tais

como o encaixe perfeito entre os elementos, dentre outros.

5. O elemento-chave para os atores residiu na capacidade ou não da ferramenta em explicar

o que se pode fazer ou não, tomando para sí algumas tarefas que exigem atenção, como a

analise em algum nível da validade da solução.

3.1.3 Coleta dos requisitos funcionais

Com base nas informações obtidas durante a analise prévia do problema, dos casos

de uso, analise de ferramentas existentes, assim como discussão com os atores envolvidos,

surgiram ideias de funcionalidades, das quais foram selecionados alguns requisitos funcionais

mínimos para se chegar ao objetivo deste projeto assim como a solução dos problemas principais

nos casos de uso.

1. Deve ser possível executar, salvar ou carregar automações construídas pelo ator de forma

que se possa reutilizar estas automações, construídas anteriormente no programa. Tam-

bém é preciso que seja possível descartar a automação.

2. Dois elementos, um capaz de executar a ação de clicar uma vez em uma área da tela e

outro capaz de executar a ação de clicar duas vezes em uma área da tela; o ator deve

ser capaz de escolher a área da tela para cada instância do elemento e o elemento deve

representar a área onde irá realizar a ação.

3. Um elemento capaz de esperar por uma alteração na tela ou evento que indique que a

automatização pode prosseguir para as próximas tarefas deﬁnidas pelo ator.

4. Um elemento capaz de digitar textos nos campos do programa a ser automatizado, como

se fosse o usuário digitando.

5. Elementos complementares que consigam expressar a lógica, condições, repetições ações

e valores tais como números e textos.

6. Um elemento capaz de ler ou gravar um arquivo de texto de forma que se possa alterar

o texto lido ou que se possa apenas copiar o arquivo para outro lugar, podendo mudar o

nome.

7. Um elemento que permita tomar decisões que alterem o ﬂuxo de automação.

8. Uma forma de pausar ou continuar a simulação.

3.2 Modelagem

Para que um software possa automatizar outro software com interface gráﬁca, é neces-

sário que o software que realiza a automação possa enviar informação para o software a ser

automatizado assim como sua interface gráﬁca. Analogamente, é preciso que o software auto-

matizador possa receber informação do software a ser automatizado.

Possibilitar que o software automatizador envie e receba informações para o software

a ser automatizado inicialmente envolve estabelecer quais são as possíveis entradas e saídas

de informação do software a ser automatizado sabendo que este desconhece a existência do

automatizador, para em seguida, deﬁnirmos as entradas e saídas necessárias para que o software

automatizador possa estabelecer a comunicação necessária com o software a ser automatizado

por meio de suas entradas e saídas.

Após conhecermos as entradas e saídas do software a ser automatizado é possível mo-

delar as entradas e saídas do software automatizador, visando enviar e receber informações

do software que queremos automatizar. Ao mesmo tempo, será modelada a entrada, saída e os

componentes internos que dão ao software automatizador, as condições necessárias para realizar

as funcionalidades concebidas durante a coleta de requisitos, observando também, a proposta

deste projeto e conhecimentos obtidos analisando outras ferramentas existentes durante o es-

tudo dos casos de uso. A entrada e saída precisará também ser modelada considerando como

o ator ou usuário irá interagir com o software automatizador para que este realize a automação

necessária.

3.2.1 Entradas e saídas do software a ser autoamatizado

Para deﬁnir as entradas e saidas do software a ser automadizado, se interagiu e observou

os modelos matemáticos agrícolas de simulação de culturas agrícolas escolhidos para serem

automatidados neste projeto. Durante as observações, considerou-se quais eram os elementos

com com que se podia interagir assim, forma de interação e resultados observados, a ﬁgura3.4

descreve como os modelos recebem e produzem as entradas e saídas. Observou-se que os

modelos podem receber dois tipos de entrada e produzir dois tipos de saída:

• entradas:

ações: Interações que resultassem em algum evento ou resposta do software.

dados: fornecer de informações, arquivos, preencher campos, dentre outro, podendo

ou não serem precedidos de uma ação.

• saídas:

eventos: Eventos ou respostas decorrentes da interação com o software que buscam

informar o usuário de alguma condição atingida no software.

dados: O produto ﬁnal esperado pelo usuário, decorrente da realização de uma simu-

lação.

Como é possível observar na ﬁgura3.4, as ações correspondem a interações de entrada

que podem resultar em alguma mudança da interface e ou do software, logo, produzem eventos

ou dados como saída, podendo inclusive produzir ambos.

Os dados quando considerados como entrada, podem ser inseridos de duas formas; após

algum evento, que indique para o usuário que o mesmo pode colocar os dados no componente

desejado, como em um textﬁeld, onde o usuário pode inserir diversos valores tal como números,

texto ou a localização de arquivos; ou ainda podem ser inseridos automáticamente, caso o pro-

grama sempre procure por arquivos em algum local especíﬁco. Em geral, inserir dados resulta

Figura 3.4: Descrição das entradas e saídas do software a ser automatizado, a grande ceta verde

mostra que é possível inserir arquivos no software, a vermelha, que é possível obter arquivos do

software, e a laranja indica que, não somente mensagens, mas qualquer componente da interface

pode representar um evento.

em algum evento observável.

Quando consideramos os eventos de saída, estas resultam, ou de alguma entrada de

dados automática, ou de alguma ação. Os eventos procuram informar o usuário de alguma con-

dição satisfeita, como por exemplo, sucesso na inserção de um arquivo, ou de algum problema

que deve ser observado, como por exemplo, algum campo preenchido incorretamente, ou que

por exemplo, um elemento recebeu o evento e espera pela inserção de dados.

Finalmente, considerando os dados de saída, podem ser observados duas formas de

saída, dados que são apresentados em componentes da interface gráﬁca, no caso dos modelos

observados, podemos citar componentes como tabelas e gráﬁcos; ou como resultado em arqui-

vos, que no caso dos modelos observados, são arquivos de texto. Os dados de saída podem ser

gerados tanto por eventos como automáticamente; quando gerados automáticamente, se deve

ao fato de que o modelo tem a capacidade de acessar e carregar automaticamente resultados

produzidos em algum momento no passado.

Uma ultima observação que podemos fazer é que, do ponto de vista dos modelos obser-

vados, e até mesmo de uma grande parte dos softwares com interface gráﬁca, podemos observar

que todas as saídas e inclusive a entrada de dados, em algum momento, são produto de alguma

ação, como por exemplo ações externas ao software que não são consideradas na ﬁgura3.4,

como o ato de executar o software a ser automatizado, ação realizada no sistema operacional.

Logo, eu não só preciso ser capaz de interagir com o software mas também com o sistema

operacional em algum nível.

3.2.2 Modelagem do software Automatizador

Figura 3.5: Erro obtido pelo autor no programa Sikuli.

3.3 Desenvolvimento do software

3.3.1 Interação entre automatizador e software a ser automatizado

3.3.2 Construção de automatizações

3.3.3 Codiﬁcação

O desenvolvimento do software foi dividido em 3 problemas que deﬁnem as principais

necessidades do software para que seja possível obter as funcionalidades previstas durante a

discussão dos requisitos funcionais.

O primeiro problema a ser solucionado foi a utilização da biblioteca Blockly em uma

aplicação local com o objetivo de ter maior acesso aos recursos do sistema.

Em seguida foi solucionado como realizar a interação com o sistema operacional e as

entradas de baixo nível tais como mouse e teclado, assim como um método para analisar e

pesquisar em imagens para encontrar os locais selecionados pelo usuário onde clicar.

Como escopo foram delimitados alguns pré-requisitos necessários para utilizar a solução

proposta neste trabalho, onde, o software deve ser uma aplicação desenvolvida usando Java e

JavaScript.

3.3.4 Blockly em uma aplicação Java

Em um primeiro momento, com o objetivo de rodar o Blockly, uma biblioteca JavaScript

100% client side dependente de um ambiente web, em uma aplicação java, optou-se por uma

solução que envolve uma aplicação JavaFX com um cliente web embutido, descrita de forma

geral na imagem 3.6.

Figura 3.6: Estrutura geral da solução.

O software ao iniciar carrega a página da aplicação web desenvolvida com base na bibli-

oteca Blockly em uma instância da classe WebEngine, contida na plataforma JavaFX, sendo

que esta instância pertencente a um objeto da classe WebView também oriunda da plataforma

JavaFX, responsável pela gestão e renderização da página web na interface gráﬁca de uma apli-

cação JavaFX.

Foi utilizada a funcionalidade LiveConnect, presente na maioria dos navegadores web,

que permite a comunicação entre o navegador e aplicativos java para conectar o software e a

aplicação web. Foi desenvolvida a classe JavascriptMsgr com o objetivo de estabelecer os

métodos de comunicação entre a aplicação web e o software, contendo uma referência para o

objeto instanciado da classe javafx.scene.web.WebEngine com o qual cria um objeto

netscape.javascript.JSObject que torna a classe JavascriptMsgr visível para

a aplicação web.

A classe JavascriptMsgr trata tanto as mensagens vindas da aplicação web como as

mensagens enviadas do software, a imagem 3.7 apresenta dois exemplos de métodos presentes

na classe JavascriptMsgr em trechos distintos

, onde o primeiro envia uma mensagem

para a aplicação web e o segundo recebe uma mensagem.

1 / / método que envia uma String contendo o arquivo XML gerado na ultima vez em que foi

2 / / salvo a blockly.mainWorkspace

4 public void loadBlocks(String xml) {

5 com.sun.javafx.application.PlatformImpl.runAndWait(() ->{

6 String escaped = StringEscapeUtils.escapeEcmaScript(xml);

7 engine.executeScript("loadBlocks(\""+ escaped +"\")");

8 });

9 }

11 / / método que recebe um pedido para esperar enquanto não localizar uma imagem na

12 / / pasta raiz, recebe um endereço relativo na pasta raiz do software e um valor

13 / / de intervalo em milissegundos que deve esperar a cada procura sem sucesso

14 public void waitImg (String imgSrc, int milisec){

15 try {

16 BufferedImage target = null;

17 target = ImageIO.read(new File(imgSrc.substring(3)));

18 BufferedImage screenshot =

19 robot.createScreenCapture(primaryScreenBounds);

20 ImageSearch is = new ImageSearch(target);

22 while(is.search(screenshot)[0] == -1){

23 screenshot = robot.createScreenCapture(primaryScreenBounds);

24 System.out.println("tried");

25 Thread.sleep(milisec);

26 }

27 System.out.println("match!");

28 } catch (IOException | InterruptedException e) {

29 e.printStackTrace();

30 }

31 }

Figura 3.7: Dois métodos da classe mediadora da comunicação entre a aplicação web e o soft-

ware

A classe possui diversos métodos que estendem as funcionalidades da aplicação web

e permitem ao software utilizar a biblioteca blockly para fornecer a biblioteca visual, gerar e

executar código.

3.3.5 Interação e pesquisa por regiões na tela do sistema operacional

A interação com o Sistema operacional é realizada por instâncias da classe java.awt.Robot

capaz de gerar eventos de sistema, nativos. Apesar de ter sido desenvolvida com o objetivo prin-

cipal de realizar testes automatizados e aplicações autoexecutáveis, por ser capaz de manipular

mouse e teclado em nível de sistema, pode ser utilizada para qualquer tarefa que busque auto-

matizar o controle do sistema operacional.

código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/

Para encontrar as áreas a serem clicadas ou regiões a serem observadas na espera de

uma mudança, foi desenvolvida a classe ImageSearch com uma solução própria de pesquisa

otimizada para imagens, que analisa uma imagem capturada da tela do sistema em busca de

referências exatas das áreas escolhidas pelos usuários.

Diversas outras soluções foram analisadas como a biblioteca OpenCV (OPENCV, 2015)

ou ainda o framework brasileiro de processamento de imagens em Java, Marvin (ARCHANJO;

ANDRIJAUSKAS; MUÑOZ, 2008). Porém outras soluções traziam diversos problemas que

não se justiﬁcavam, variando da necessidade de mais bibliotecas, adaptação a uma abordagem

mais complicada e distante da necessidade do projeto ou ainda limitações em termos de plata-

formas.

A abordagem é descrita na ﬁgura 3.8, se trata de extrair da área selecionada pelo usuário,

dois pixels, um com o maior valor de cor RGB dentre todos e outro com o menor valor dentre

todos, assim como a distância ’x’ e ’y’ destes dois pixels da origem. Por questões de otimização

as cores nas imagens são analisadas como se fossem inteiros absolutos de 32 bits.

Posteriormente percorre quase todos os pixels da imagem capturada da tela do sistma,

de x = 0 até x = (larguraCaptura - larguraArea), usando a posição em que se encontra como

âncora para veriﬁcar nas posições salvas dos pixels extraídos da área são iguais aos pixels na

posição da imagem.

Caso os 2 pixels sejam iguais, inicia-se uma análise de uma malha esparsa de pixels

na área, onde é somado a diferença dos pixels da imagem extraída pelo usuário e a imagem

capturada da tela, caso a diferença no ﬁnal for zero, signiﬁca que foi encontrado uma área na

imagem capturada igual à imagem da área que o usuário escolheu e neste caso a função retorna

a posição ’x’ ’y’ da âncora.

Os métodos principais da classe ImageSearch

, podem ser observados na imagem

3.9.

O método StoreTarget percorre a imagem que o usuário selecionou para ser clicada

ou analisada e compara o valor de cada pixel com variáveis auxiliares, onde posteriormente

sobrescreve o valor destas variáveis se o pixel for realmente um valor maior ou menor do que

os considerados anteriormente.

Já o método search procura pelo máximo ou mínimo na imagem capturada pelo soft-

ware, quando encontra a área que contem nas mesmas posições o valor máximo e mínimo,

código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/

Figura 3.8: descrição visual da tarefa realizada pela classe ImageSearch.

analisa a área um pixel a cada três, caso a soma de todas as diferenças da área de um valor 0

todas as threads são paradas e a posição do pixel âncora ou origem da área é retornado. A tarefa

também é dividia entre os núcleos do processador do usuário para obter melhor performance e

o método apenas retorna quando o todas as threads iniciadas pela pesquisa terminarem.

3.3.6 modelagem das funcionalidades no softwares

A interface do software foi desenvolvida para ser o mais simples e limpa possível com o

objetivo de diminuir duvidas ou confusão dos usuários, existem, além do botão nativo de lixeira,

mais três botões, um para executar a simulação, um para carregar um quebra-cabeças que tenha

sido salvo e outro para salvar um quebra-cabeças atualmente no software. O programa utiliza o

único formato de armazenamento em arquivo disponível na biblioteca Blockly, a linguagem de

marcação XML. É possível ver a interface na ﬁgura 3.10.

Para fornecer as funcionalidades foram deﬁnidos quatro blocos que expressam funcio-

nalidades fundamentais para a automatização, dois blocos que expressam a habilidade de clicar

em algum lugar da interface, um para clique duplo e outro para clique único, também, um bloco

que permite esperar por algum evento visual, para que seja possível esperar a ﬁnalização do

processamento dos modelos, e por último um bloco que permite digitar texto na entrada de

texto do sistema operacional.

É possível observar os blocos na imagem 3.11 e a descrição formal em JavaScript destes

blocos na ﬁgura 3.123.13

Como é possível ver o bloco Image_Wait e os blocos que representam as ações de cli-

que de mouse, click_doble_special e click_single_special utilizam um campo

próprio chamado FieldImageButton, desenvolvido observando-se o campo original pre-

código completo disponível em https://github.com/RomuloPBenedetti/TCC/tree/master/Software/src/

2 public final void storeTarget(BufferedImage t) {

3 this.t = t; int rgb; tWidth = t.getWidth(); tHeight = t.getHeight();

4 for(int x = 0; x < tWidth; x++) {

5 for (int y = 0; y < tHeight; y++) {

6 rgb = t.getRGB(x, y);

7 if (Integer.compareUnsigned(rgb, max)>0) { max = rgb; maxX = x;

maxY = y; }

8 if (Integer.compareUnsigned(rgb, max)<0) { min = rgb; minX = x;

minY = y; }

9 }

10 }

11 }

13 public final int[] search(BufferedImage i) {

15 int iWidth, iHeight, point[] = new int[2];

16 point[0] = -1; point[1] = -1;

17 int startX[] = new int[cores], endX[] = new int[cores];

18 int startY[] = new int[cores], endY[] = new int[cores];

20 iWidth = i.getWidth()-tWidth; iHeight = i.getHeight()-tHeight;

21 ExecutorService executor = Executors.newFixedThreadPool(cores);

23 for (int q = 0 ; q < cores ; q++){

24 startX[q] = (iWidth/cores)

q; startY[q] = 0;

25 endX[q] = (iWidth/cores)

(q+1); endY[q] = iHeight;

26 int fQuad = q;

28 executor.execute(() -> {

29 Thread.currentThread().setName("thread" + fQuad);

30 int difference = 100; int rgbC;

31 for (int x = startX[fQuad]; x < endX[fQuad]; x++) {

32 for (int y = startY[fQuad]; y < endY[fQuad]; y++) {

33 rgbC = i.getRGB(x + maxX, y + maxY);

34 if (rgbC == max) {

35 rgbC = i.getRGB(x + minX, y + minY);

36 if (rgbC == min) {

37 difference = 0;

38 for (int ty = 0; ty < tHeight; ty = ty +3) {

39 for (int tx = 0; tx < tWidth; tx = tx +3) {

40 difference += t.getRGB(tx, ty) -

i.getRGB(x+tx, y+ty);

41 }

42 }

43 if (difference == 0) {

44 point[0] = x; point[1] = y;

45 executor.shutdownNow();

46 }

47 }

48 }

49 if (difference == 0) break;

50 }

51 if (difference == 0) break;

52 }

53 });

54 }

55 try {

56 executor.awaitTermination(1, TimeUnit.SECONDS);

57 } catch (InterruptedException e) {

58 e.printStackTrace();

59 }

60 return point;

61 }

Figura 3.9: Métodos que analisam a imagem da área e a imagem capturada da tela do sistema

sente na biblioteca Blockly field_image

, este campo adiciona a imagem um eventListenner

o código desta classe pode ser encontrado em https://github.com/google/blockly/

Figura 3.10: Tela inicial do software desenvolvido

Figura 3.11: Blocos construídos para as operações de automação

que ao ser clicado envia uma mensagem que dá início a tarefa de captura de tela no software, que

ao ser terminada pelo usuário, envia uma mensagem contendo o caminho da imagem da área

selecionada pelo usuário que deve sofrer a ação do bloco junto com suas dimensões. Por sua

vez a aplicação web atualiza a imagem do bloco para representar a área que o usuário escolheu.

Toda a tarefa é mantida coêsa transferindo junto com estas mensagens o ID único que a

própria biblioteca Blockly gera para cada bloco assim tanto a aplicação web como o software

sempre sabem para que bloco é cada mensagem. Por questões de ﬂexibilidade e simplicidade

foi decidido utilizar a linguagem JavaScript por questões de simplicidade já que é uma das

linguagens nativas do software e disponível para os outros blocos da biblioteca por padrão já.

Quando o usuário clica no botão para executar o modelo no software, é enviado uma

mensagem para a aplicação web, pedindo que para que a biblioteca Blockly monte o código

com base no quebra-cabeça montado e por ﬁm, execute o código com a função eval.

Como é possível observar, os geradores de código foram construídos para realizar cha-

madas no no software java e portanto, a aplicação web ﬁca responsável apenas pela montagem

da lógica que guia a execução das tarefas tais como construção de repetições ou deﬁnições de

valores a serem enviados junto as mensagens para que o software as realize. É possível ver um

exemplo do código gerado por um conjunto de blocos nas ﬁguras 3.14.3.15.

1 Blockly.Blocks[’click_single_special’] = {

2 init: function() {

3 this.appendDummyInput("imageInput")

4 .appendField("clicar uma vez em:")

5 .appendField(new

Blockly.FieldImageButton("../images/icons/clickBlack.png",

30, 30, "", imageButtonEvent), "FieldImageButton");

6 this.setPreviousStatement(true, null);

7 this.setNextStatement(true, null);

8 this.setColour(60);

9 this.setTooltip(’Procura na sua tela pela região que a imagem

representa e clica no centro uma veze, para escolher, clique na

imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,

selecione onnde clicar com o mouse e aperte enter.’);

10 }

11 };

13 Blockly.Blocks[’click_doble_special’] = {

14 init: function() {

15 this.appendDummyInput("imageInput")

16 .appendField("clicar duas vezes em:")

17 .appendField(new

Blockly.FieldImageButton("../images/icons/clickBlack.png",

30, 30, "", imageButtonEvent), "FieldImageButton");

18 this.setPreviousStatement(true, null);

19 this.setNextStatement(true, null);

20 this.setColour(60);

21 this.setTooltip(’Procura na sua tela pela região que a imagem

representa e clica no centro duas vezes, para escolher, clique na

imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,

selecione onnde clicar com o mouse e aperte enter.’);

22 console.log(this.id);

23 }

24 };

26 Blockly.Blocks[’text_typer’] = {

27 init: function() {

28 this.appendDummyInput("textToType")

29 .appendField("digitar:")

30 .appendField(new Blockly.FieldTextInput("texto"), "text");

31 this.setPreviousStatement(true, null);

32 this.setNextStatement(true, null);

33 this.setColour(60);

34 this.setTooltip(’’);

35 this.setHelpUrl(’http: / / www.example.com/’);

36 }

37 };

39 Blockly.Blocks[’Image_Wait’] = {

40 init: function() {

41 this.appendDummyInput("imageInput")

42 .appendField("esperar enquanto não encontrar:")

43 .appendField(new

Blockly.FieldImageButton("../images/icons/clickBlack.png",

30, 30, "", imageButtonEvent), "FieldImageButton");

44 this.appendValueInput("miliToWait")

45 .setCheck("Number")

46 .setAlign(Blockly.ALIGN_RIGHT)

47 .appendField("procurando a cada:");

48 this.appendDummyInput()

49 .appendField("milisegundos");

50 this.setInputsInline(true);

51 this.setPreviousStatement(true, null);

52 this.setNextStatement(true, null);

53 this.setColour(60);

54 this.setTooltip(’para escolher por que imagem esperar, clique na

imagem branca do bloco, va ao local desejado aperte ctrl+shift+c,

selecione onnde clicar com o mouse e aperte enter.’);

55 this.setHelpUrl(’http: / / www.example.com/’);

56 }

57 };

Figura 3.12: Descrição dos blocos na aplicação web e seus respectivos geradores de código

1 Blockly.JavaScript[’click_doble_special’] = function(block) {

2 src =

(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");

3 running = ’if (running) {\n’;

4 calling = ’ running = java.clickIn(\"’ + src + ’\",’ + 2 + ’);\n’;

5 end = ’}\n’;

6 var code = running + calling + end;

7 return code;

8 };

10 Blockly.JavaScript[’click_single_special’] = function(block) {

11 src =

(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");

12 running = ’if (running) {\n’;

13 calling = "java.clickIn(\"" + src + ’\",’ + 1 + ’);\n’;

14 end = ’}\n’;

15 var code = running + calling + end;

16 return code;

17 };

19 Blockly.JavaScript[’text_typer’] = function(block) {

20 text = block.getFieldValue(’text’);

21 running = ’if (running) {\n’;

22 calling = " running = java.type(\"" + text + ’\");\n’;

23 end = ’}\n’;

24 var code = running + calling + end;

25 return code;

26 };

28 Blockly.JavaScript[’Image_Wait’] = function(block) {

29 src =

(block.getFieldValue(’FieldImageButton’)).replaceAll("\\\\","\\\\");

30 milisec = Blockly.JavaScript.valueToCode(block, ’miliToWait’,

Blockly.JavaScript.ORDER_ATOMIC) || ’0’

31 running = ’if (running) {\n’;

32 calling = ’ java.waitImg(\"’ + src + ’\", ’+ milisec + ’);\n’;

33 end = ’}\n’;

34 var code = running + calling + end;

35 return code;

36 };

Figura 3.13: Geradores de código java dos blocos construidos

Figura 3.14: Exemplo de um quebra-cabeça

1 var running = true; var dias;

3 for (dias = 1; dias <= 31; dias += 3) {

4 for (var count = 0; count < 10; count++) {

5 if (running) {

6 java.clickIn("../images/icons/clickBlack.png",1);

7 }

8 if (running) {

9 running = java.type("digitar alguma coisa");

10 }

11 if (running) {

12 java.waitImg("../images/icons/clickBlack.png", 200);

13 }

14 }

15 }

Figura 3.15: Exemplo do código gerado por este quebra-cabeça

4 RESULTADOS

4.1 Validando solução com os casos de teste

Com as funcionalidades desenvolvidas no software não é possível solucionar todas as

questões desenvolvidas nos casos de teste dos 3 modelos Porem é possível solucionar em geral

o problema dos modelos projetando o quebra-cabeças levando em consideração as limitações

do software.

Algumas limitações principais encontradas ao modelar um quebra-cabeças para os casos

de teste coletados foram:

• O software não é capaz de suavizar a criticidade com a qual procura os campos a serem

clicados, logo qualquer diferença já torna impossível para o software localizar o campo

novamente.

• O software não é capaz de se deslocar pela interface do sistema operacional, ir para a área

de trabalho ou navegar entre as janelas abertas do sistema.

• O software não é capaz de editar arquivos de texto. Embora possua diversas capacidades

para processar textos dentre seus blocos, não ha nenhum bloco capaz de abrir um arquivo

armazenado em alguma pasta do sistema ou ainda ler texto da tela.

• Apesar de ser capaz de esperar por mudanças gráﬁcas na tela, o software não é capaz de

tomar decisões lógicas na ocorrência de uma mudança gráﬁca, habilidade relevante para

o tratamento de erros ou seguimento de múltiplos ﬂuxos.

Dentre outras limitações não fundamentais, esta o fato de que o software não é capaz de

pausar ou reiniciar simulações em andamento, assim como também não ha feedback visual do

software quando o mesmo ﬁnaliza a tarefa ou encontra algum erro.

4.1.1 Simanihot

Foi validada apenas a abstração lógica da linguagem visual modelando um quebra-

cabeças para o caso de uso do modelo Simanihot onde todos os problemas fundamentais para a

solução do problema proposto no caso de uso são solucionados dentro da lógica disponibilizada

pelo conjunto de peças do software, como é possível ver na ﬁgura 4.1.

Em especial, é necessário conﬁgurar o quebra-cabeças para fechar e reabrir a aplicação,

já que o software não possibilita deﬁnir um nível de similaridade das áreas a serem clicadas,

esperando uma similaridade exata, o que não ocorre de simulação em simulação, já que a cada

simulação o texto que se encontra nos campos de texto é diferente do anterior.

Figura 4.1: Exemplo de um quebra-cabeça

5 CONCLUSÃO

A proposta inicial deste trabalho consistia principalmente em apresentar uma solução de

automação de interfaces gráﬁcas de forma simpliﬁcada com base na biblioteca de programação

visual Blockly dentro do contexto de modelos de simulação de culturas agrícolas. Entretanto

o resultado ﬁnal desta pesquisa trata-se não de uma solução total dos problemas apresentados,

mas de um software que oferece a possibilidade de automatização de alguns problemas com um

escopo não tão grande como o dos problemas propostos, com base nas conclusões tomada du-

rante o desenvolvimento, a partir dos percalços e da análise constante da amplitude da proposta

e das necessidades durante a validação das abordagens em questão.

Como contribuição este trabalho apresentou uma abordagem diferenciada na programa-

ção de tarefas automatizadas expondo de forma mais simpliﬁcada lógica comum em linguagens

de programação e script tradicionais, fornecendo uma ferramenta que pode descrever de forma

muito ﬂexível interações com a interface gráﬁca e permitindo em algum nível realizar a automa-

tização de parte das tarefas maçantes presentes na interação com interfaces gráﬁcas de modelos

matemáticos de simulação de culturas agrícolas mais simples.

A lista a seguir, não exaustiva, expõe em ordem de relevância, uma lista de algumas

melhorias que poderiam ser incorporadas em uma nova versão deste projeto:

• Tratar arquivos com conteúdo de texto, permitindo copiar arquivos para outros locais,

criar arquivos com novas informações, renomeá-los e processar e extrair informações

destes textos.

• Reﬁnar a forma com a qual o programa localiza e clica nos elementos gráﬁcos, seja

pela adição de procura por similaridades e áreas não exatas, ou por novos métodos para

deﬁnição da área onde se deve clicar.

• Expandir a interação com o sistema operacional de forma que o software possa procurar

dentre diversas janelas e na área de trabalho.

• Fornecer feedback visual ao ﬁnalizar automatizações ou receber erros durante a execução

de uma automatização.

• Obter uma forma mais eﬁciente de captura de tela já que a captura de tela realizada pela

classe Robot além de lenta pode produzir artefatos e não capturar alguns elementos

dinâmicos de alguns programas.

• Oferecer blocos que simpliﬁquem elementos lógicos já presentes na biblioteca Blockly

permitindo a formulação de quebra-cabeças de automatização mais simples.

• Reﬁnar os detalhes em geral da aplicação como salvamento e carregamento de quebra-

cabeças de forma que sejam salvas também as imagens pré selecionadas, fornecimento

de conﬁgurações para troca de idioma e possibilidade de pausar, continuar e reiniciar

quebra-cabeças.

REFERÊNCIAS

APPINVENTOR. Accessed:2016-02-19, http://appinventor.mit.edu/.

ARCHANJO, G.; ANDRIJAUSKAS, F.; MUÑOZ, D. Marvin–A Tool for Image Processing

Algorithm Development. Technical Posters Proceedings of XXI Brazilian Symposium of

Computer Graphics and Image Processing, [S.l.], v.1, n.1, p.5–6, 2008.

AUTOIT. Accessed: 2016-02-19, https://www.autoitscript.com/site/

autoit/.

AUTOMATOR. Accessed: 2016-02-19, https://developer.apple.com/

library/mac/documentation/AppleApplications/Conceptual/

AutomatorConcepts/Automator.html.

BARRY, E. J.; KEMERER, C. F.; SLAUGHTER, S. A. How software process automation

affects software evolution: a longitudinal empirical analysis. JOURNAL OF SOFTWARE

MAINTENANCE AND EVOLUTION: RESEARCH AND PRAC, [S.l.], p.31, 2007.

BLOCKLYGAMES. Accessed: 2016-02-19, https://blocklyResource-games.

appspot.com/.

BLOCKLYRESOURCE. Accessed: 2016-02-19, https://developers.google.com/

blocklyResource/.

DECISION Support System for Agrotechnology Transfer (DSSAT). Accessed: 2016-02-27,

http://dssat.net/.

DONMEZ, M. A.; SOONS, J. A. Impacts of Automation on Precision. [S.l.: s.n.], 2008.

p.117–126.

GNU Make. Accessed: 2016-02-19, https://www.gnu.org/software/make/.

KOEGEL, J.; HEINES, J. M. Improving Visual Programming Languages for Multimedia

Authoring. World Conference on Educational Multimedia and Hypermedia, [S.l.], p.8,

1993.

MARRON, A.; WEISS, G.; WIENER, G. A Decentralized Approach for Programming Interac-

tive Applications with JavaScript and Blockly. AGERE!, [S.l.], p.13, 2012.

MYERS, G. J.; SANDLER, C.; BADGETT, T. The art of software testing. [S.l.]: John Wiley

& Sons, 2011.

NOF, S. Y. Springer Handbook of Automation. [S.l.]: Springer, 2009.

OPENCV. Accessed: 2016-06-03, http://opencv.org/.

PARASURAMAN, R.; SHERIDAN, T. B.; WICKENS, C. D. A Model for Types and Levels of

Human Interaction with Automation. IEEE Systems, Man, and Cybernetics Society, [S.l.],

v.1, n.1, p.286–297, 2000.

ROBOT Framework. Accessed: 2016-01-12, http://robotframework.org/.

SHU, N. C. Visual Programming. [S.l.]: Van Nostrand Reinhold, 1988.

SIKULI. Accessed: 2016-04-19, http://www.sikuli.org/.

SILVEIRA JúNIOR, G. da et al. Análise da ferramenta de programação visual blockly como

recurso educacional no ensino de programação. [S.l.: s.n.], 2015.

SIMANIHOT. Accessed:2016-02-27, http://w3.ufsm.br/simanihot/.

SOYSIM. Accessed: 2016-02-27, http://soysim.unl.edu/.

STRECK, N. A. et al. Simanihot: um modelo de simulação do crescimento, desenvolvimento

e produtividade de mandioca. 13ž Reunião Técnica Estadual da mandioca e 5ž Reunião

Técnica Estadual da batata-doce,Cerro Largo -RS: Emater-RS, [S.l.], v.1, n.1, p.55, 2015.

TESTCOMPLETE. Accessed: 2016-04-19, https://smartbear.com/product/

testcomplete/overview/.

UIPATH. Accessed: 2016-04-19, http://www.uipath.com/.

UNIX Shell. Accessed: 2016-02-19, http://www.cs.columbia.edu/~sauce/

tutorial/shell.html.

VENKATRAMAN, N. IT-Enabled Business Transformation: from automation to business

scope redeﬁnition. ABI/INFORM Global, [S.l.], p.73, 1994.